La versión 2.0 de HTMX, publicada en junio de 2024, llegó con un mensaje sobrio: la librería se considera terminada. No hay roadmap frenético, no hay integración forzada con el framework del mes, no hay runtime que reescriba el DOM a tu espalda. Esa quietud es precisamente el argumento de venta. Mientras React, Vue y Angular iteran a ritmo de frontend moderno, HTMX defiende que la web nunca necesitó salir del modelo que ya funcionaba: un navegador que pide documentos y un servidor que los devuelve.
Lo que cambia con HTMX es que esos documentos pueden ser fragmentos, pueden dispararse con cualquier evento y pueden insertarse en cualquier punto del árbol. Todo eso se declara con atributos HTML. No hay bundle, no hay paso de build, no hay estado duplicado entre cliente y servidor. El servidor renderiza HTML completo en la carga inicial y fragmentos HTML en cada interacción. El cliente los acopla al DOM. Fin del modelo.
La filosofía hipermedia frente a la SPA
Para entender HTMX hay que recuperar una palabra que la mayoría de desarrolladores web aprendió en abstracto y luego olvidó: HATEOAS. El servidor no sólo devuelve datos, también devuelve las transiciones posibles a continuación, codificadas como enlaces y formularios. Eso es la web que describió Roy Fielding, y es el motor de la arquitectura REST original. Las SPA rompieron ese modelo cuando decidieron que el cliente iba a mantener su propio estado, pedir JSON y construir la interfaz a partir de datos crudos. Ganaron en fluidez percibida y perdieron en algo menos visible: la cohesión entre el estado real del sistema y lo que el usuario ve.
HTMX recupera el modelo hipermedia sin pedirte nostalgia. Un botón con hx-get dispara una petición a una URL, el servidor responde con HTML, y hx-target indica qué parte de la página se sustituye. La variante hx-post publica un formulario, recibe la respuesta y aplica la misma sustitución. El atributo hx-swap controla la semántica: reemplazar el elemento entero, inyectar dentro, anteponer, añadir al final, o aplicarlo sólo si hay cambios. Con hx-trigger se afina cuándo se lanza la petición: un clic, una tecla pulsada con debounce, un intervalo, incluso cuando el elemento entra en el viewport. Con hx-push-url la URL del navegador se actualiza y el botón atrás funciona como en cualquier web. Todo lo que en una SPA requiere un router, un store y un hook de efectos aquí son tres atributos.
<input name="q"
hx-get="/buscar"
hx-trigger="keyup changed delay:300ms"
hx-target="#resultados"
hx-push-url="true">
<div id="resultados"></div>Un único ejemplo basta porque el resto del vocabulario se deduce. Si sabes dónde inyectar, cuándo disparar y qué verbo HTTP usar, ya conoces el ochenta por ciento del API.
Cuándo paga el renderizado en servidor
La pregunta honesta no es si HTMX es mejor que React, sino en qué tipo de producto desaparecen las ventajas de una SPA. Un panel de administración interno con cien pantallas de CRUD no gana nada por tener estado cliente. Un checkout de comercio electrónico tampoco: el servidor tiene que validar en cada paso, calcular impuestos, consultar stock, y la interfaz sigue al resultado de esa lógica. Una intranet, un portal de noticias, un dashboard de métricas que refresca cada treinta segundos, un backoffice de soporte: todos ellos encajan con el modelo hipermedia sin esfuerzo.
Hay un segundo criterio, menos técnico y más honesto: el tamaño del equipo. Montar una SPA seria implica decidir framework, gestor de estado, estrategia de routing, librería de formularios, tooling de build, testing de componentes, pipeline de despliegue separado del backend y una pila de dependencias que envejecen a ritmos distintos. Un equipo de dos personas trabajando sobre Django o Rails no puede sostener esa complejidad sin sacrificar el producto. HTMX elimina esa bifurcación. El mismo desarrollador que escribe la vista del backend añade los atributos y obtiene interactividad.
El tercer criterio es operativo. Un despliegue único, un dominio, un proceso de servidor, un log. Sin CDN de assets separada, sin CORS, sin sincronización de versiones entre API y cliente. La ganancia en simplicidad de infraestructura es real y se nota en incidentes: cuando algo falla, hay un único sitio donde mirar.
Los límites reales
HTMX no sustituye todo. Las aplicaciones con colaboración en tiempo real con múltiples cursores, los editores de canvas, las herramientas de dibujo vectorial y cualquier cosa que deba funcionar sin red caen fuera del modelo hipermedia. Cada interacción en HTMX implica una petición al servidor, y aunque el payload sea pequeño y la latencia aceptable en LAN o con el servidor cerca del usuario, no compite con la respuesta instantánea de una SPA que ya tiene todo el estado en memoria.
Tampoco conviene forzarlo cuando la lógica de interfaz es genuinamente compleja en cliente. Un wizard con validaciones cruzadas entre pasos, una tabla con filtros combinables y ordenación multi-columna, o una calculadora con preview en vivo son casos donde Alpine.js complementa bien a HTMX para la interactividad local y HTMX se ocupa de lo que toca al servidor. Esa combinación cubre la mayor parte del espacio intermedio sin tener que introducir un framework completo.
Hay además un problema de ecosistema del que conviene avisar. Los PaaS orientados a frontend moderno están optimizados para el modelo SPA. Desplegar HTMX sobre Vercel o Netlify es posible pero desaprovecha su arquitectura. El terreno natural de HTMX son los hosts tradicionales, los contenedores, los servidores compartidos y los clusters Kubernetes. Es una decisión de pila completa, no sólo de frontend.
Conclusión
HTMX no es una moda ni una provocación. Es la constatación de que durante quince años la industria aceptó una complejidad que no siempre estaba justificada. La versión 2.0 marca que la librería ha llegado a un estado de madurez donde el ritmo de cambios se mide en años, no en semanas, y eso es exactamente lo que se le pide a una base tecnológica sobre la que construir productos que duren. Para un equipo pequeño con un backend expresivo y un producto que vive del contenido, los formularios y las vistas de datos, elegir HTMX significa gastar energía en el dominio del negocio en lugar de en la plomería del frontend. Para un producto que necesita una experiencia cliente rica y desconectada, sigue sin encajar. Ese margen de honestidad es precisamente lo que hace a HTMX recomendable: sabe lo que es y lo que no.
